|
|
|
|
|
|
|
it's nice to think through the logic of your program before expending time and energy on it. Remember those times when you quickly developed an application without architectural forethought, only to later forget how the lines of code work together? A documented architecture, complete with design models, helps preserve the thought processes in a common, easy-to-remember notation that serves as a snapshot of your mind at the time you designed the application. |
|
|
|
|
|
|
|
|
Among the many factors that contribute to deviating from an architecture, three prominent ones include |
|
|
|
|
|
|
|
|
Lack of executive sponsorship of a project |
|
|
|
|
|
|
|
|
Inexperienced system architects |
|
|
|
|
|
|
|
|
Lack of Executive Sponsorship of a Project |
|
|
|
|
|
|
|
|
One of the most difficult aspects of learning OOP is the discipline it takes for a programmer to adhere to the specifications of the application's predefined architecture. For those readers who must develop applications in a corporate environment, nothing is more frustrating than a team that isn't committed to a common architecture. There you are, sweating out the details of your object-oriented application, but another programmer on the team decides to ignore the design models and develop it his way! For object-oriented design models to have any real and effective meaning in the long run, an executive sponsor (someone in upper management) must ensure an environment for rewarding adherence to the architecture. This is important in the absence of healthy teamwork. Those who continue to ignore design models should be isolated from the object-oriented project. Lack of effective executive sponsorship can hamper the development of a robust, extensible, reusable system. |
|
|
|
|
|
|
|
|
Inexperienced System Architects |
|
|
|
|
|
|
|
|
Just as devastating as lack of executive sponsorship is inexperience among the ranks of the architects. The architect's chief duty is to develop and evolve the architecture of the proposed application. From the methods and properties of each class's interface to the communication channels between objects, the architect makes fundamental, far-reaching decisions about the very nature of the application. For large companies, such decisions can cost into the tens of millions. For small, independent software developers, a faulty architectural decision can mean hours of phone calls and emails from angry customers. Inexperienced architects tend to not understand the iterative, incremental nature of the object-oriented project. For this reason, experienced object technologists easily identify such individuals, but novices to OOP might not have this ability. The success of any |
|
|
|
|
|